The invention concerns generally the technology of handling updates which may consist of several lower-level operations which must all succeed or all fail in a consistent manner. Especially the invention concerns the technology of utilizing a memory address translation layer when performing transactions.
The concept of performing a transaction is widely used in the field of maintaining file systems where integrity of data and obedience to certain business rules are of primary concern. As an example we may consider a banking application where an accounts file lists all accounts with their currently valid balance, and a separate account entries file lists all performed account entries. Let us assume that a new record has been made to the account entries file, describing the payment of a certain sum of money to or from a certain account. However, a corresponding update operation to the accounts file was not performed. The result is a violation of data integrity in the file system: the balance of a certain account read from the accounts file is not the same as the one obtained by going through the records in the account entries file. This kind of conflict is usually known as a transaction consistency violation. Another example of a dangerous situation is a so-called business rule violation, which means that a certain application-specific rule is violated: for example an entry was made to an account that should have already been closed for approval.
The concept of transaction means that all such lower-level operations that cause changes to the data in a file system are grouped together to form an entity where all operations must either succeed together or fail together. The lower-level operations are also known as update operations. A transaction is usually divided into three successive phases, namely starting a transaction, updating data, and committing the transaction. If a fatal system failure (e.g. a system reset) occurs, either all update operations are performed or no changes are made to the data, depending on whether the commit phase had been reached or not. A fatal system failure during an already started commit phase causes it to be suspended but finished at the next start-up of the system. If the fatal system failure occurred before a transaction reached its commit phase, all traces of that transaction are automatically deleted during the next start-up.
The transaction mechanism usually supports a reverse operation known as the rollback transaction, which means canceling all update operations that were made at the updating phase instead of making them permanent through committing.
FIG. 1 illustrates a simple, conventional file system which can be used to perform transactions. A control unit 101 manages both a log file 102 and a database file 103. The control unit 101 writes the operations that constitute a transaction first into the log file 102 according to arrow 104. After all operations have been successfully written into the log file 102, the control unit 101 rewrites them, i.e. makes the corresponding changes, to the database file 103. This operation may be seen as transferring the changes from the log file 102 to the database file 103 according to arrow 105.
If we compare the log file arrangement of FIG. 1 to a straightforward non-transaction oriented updating of data in the database file 103, we note that the former doubles the amount of file write operations and introduces a file read operation which is not present in the latter. It is clear that such loading of the file system must have certain harmful effects especially in large-scale systems like banking applications where the daily number of transactions is easily in the order of hundreds of thousands or millions.